DUDLEY  KNOX  LIBRARY 
NAVAL  POSTGRADUATE  SCHOOL 
MONTEREY,  CALIFORNIA  93943-5008 


NAVAL  POSTGRADUATE  SCHOOL 

Monterey,  California 


THESIS 


DESIGN 
SYSTEM 

OF  A 
FOR 

GENERIC 
USE  WITH 

by 

DECISION  : 
THE  FAMIS 

SUPPORT 
SYSTEM 

Renee  Lefebvre  Rodeck 

March 

L986 

Th< 
Co 

ssis  Adv 
-Advisor 

'isor 

•  • 

: 

Jack  LaPatra 
Michael  J.  Spencer 

Approved  for  public  release;  distribution  is  unlimited 


T226813 


:T)'RirY  CLASSIFICATION  OF   THIS   PAGE 


REPORT  DOCUMENTATION  PAGE 


'   REPORT  SECURITY  CLASSIFICATION 


1b.  RESTRICTIVE   MARKINGS 


"   SECURITY  CLASSIFICATION  AUTHORITY 


;   DECLASSIFICATION /DOWNGRADING  SCHEDULE 


3     DISTRI8UTION/AVAILABIUTY  OF   REPORT 

Approved  for  public  release; 
distribution  is  unlimited 


'PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 


5    MONITORING  ORGANIZATION  REPORT  NUMBER(S) 


NAME  OF  PERFORMING  ORGANIZATION 

aval  Postgraduate  School 


6b    OFFICE  SYMBOL 
(If  applicable) 

Code    54 


7a    NAME  OF  MONITORING  ORGANIZATION 

Naval  Postgraduate  School 


i  ADDRESS  (Oty,  State,  and  ZIP  Code) 

onterey,    CA      9394  3-5000 


7b.   ADDRESS  (Oty,  State,  and  ZIP  Code) 

Monterey,  CA   93943-5000 


NAME  OF  FUNDING/SPONSORING 
ORGANIZATION 


8b    OFFICE  SYMBOL 
(If  applicable) 


9    PROCUREMENT  INSTRUMENT  IDENTIFICATION   NUMBER 


I  ADDRESS  (Oty,  State,  and  ZIP  Code) 


10    SOURCE  OF  FUNDING  NUMBERS 


PROGRAM 
ELEMENT  NO 


PROJECT 
NO 


TASK 
NO 


WORK   UNIT 
ACCESSION   NO 


TITLE  (Include  Security  Classification) 

ESIGN  OF  A  GENERIC  DECISION  SUPPORT  SYSTEM  FOR  USE  WITH  THE  FAMIS  SYSTEM 

PERSONAL  AUTHOR(S) 

odeck,  Renee  Lefebvre 


TYPE  OF  REPORT 

aster's    Thesis 


13b    TIME  COVERED 
FROM  TO 


14    DATE  OF  REPORT    (Year,  Month,  Day) 

1986    March    27 


15    PAGE   COUNT 

60 


SUPPLEMENTARY   NOTATION 


COSATI  CODES 


FIELD 


GROUP 


SUB-GROUP 


18    SUBJECT  TERMS  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 
FAMIS,     NCS,     NETS,     PSN,     DSS ,     LS ,     KS ,     PPS 


ABSTRACT  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 

n  a  national  emergency,  allocation  of  scarce  communication  resources  to 
ecovery  agents  will  be  vital  to  recovery  efforts.   To  facilitate  such 
llocation,  the  National  Security  Souncil  is  developing  the  Fly-Away 
mergency  Management  Information  System  (FAMIS) . 

ihis  thesis  will  discuss  the  possible  characteristics  of  a  decision 
upport  system  as  a  needed  feature  of  the  FAMIS  system. 


D'STRi3UTiON/ AVAILABILITY  OF  ABSTRACT 
|  jj  UNCLASSIFIED/UNLIMITED       □  SAME  AS  RPT 
i     NAME  OF  RESPONSIBLE  INDIVIDUAL 

Jack   LaPatra 


Dotic  USERS 


21    ABSTRACT  SECURITY  CLASSIFICATION 

Unclassified 


22b  TELEPHONE  (Include  Area  Code) 
(408)     646-2249 


22c    OFFICE   SYMBOL 

54Lp 


FORM  1473,  84  mar 


83  APR  edition  may  be  used  until  exhausted 
All  other  editions  are  obsolete 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


Approved  for  public  release;  distribution  is  unlimited. 


Design  of  a  Generic  Decision  Support  System 
for  Use  with  the  FAMIS  System 


by 


Renee  Lefebvre  Rodeck 
Lieutenant.  United  States  Navy 
B. A. ,  University  of  California,  1974 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  INFORMATION  SYSTEMS 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
March  1986 


ABSTRACT 

In  a  national  emergency,  allocation  of  scarce  communica- 
tion resources  to  recovery  agents  will  be  vital  to  recovery 
efforts.  To  facilitiate  such  allocation,  the  National 
Security  Council  is  developing  the  Fly-Away  Management 
Information  System  (FAMIS). 

This  thesis  will  discuss  the  possible  characteristics  of 
a  decision  support  system  as  a  needed  feature  of  the  FAMIS 
system. 
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I.  BACKGROUND 

In  any  emergency,  the  right  decisions  must  be  made 
quickly.  The  more  information  a  decision-maker  (manager) 
has,  the  better  his  decision  is  apt  to  be.  However,  the 
more  information  a  manager  must  assimilate,  the  less  quickly 
he  can  reach  a  decision. 

This  problem  of  information  assimilation  for  decision- 
making would  become  apparent  if,  during  a  national  emer- 
gency, a  manager  was  required  to  determine  allocation  of 
scarce  communication  resources  to  many  competing  users.  The 
manager  would  be  forced  to  answer  questions  quickly:  What 
problems  need  to  be  solved?  What  users  are  out  there?  What 
resources  remain?  How  can  remaining  resources  be  used  by 
the  remaining  users  most  effectively  to  solve  problems? 

A  Decision  Support  System  (DSS)  can  aid  a  manager  in 
answering  these  kinds  of  questions  by  assimilating, 
selecting  and  presenting  needed  information  in  form  and 
volume  the  manager  can  understand  and  use  quickly. 

Such  a  DSS  would  allow  an  emergency  decision-maker  the 
option  of  considering  the  projected  outcome  of  various 
possible  choices  through  simulation  models,  selectively 
considering  only  needed  information  while  screening  out 
extraneous  data  and  seeing,  by  using  stored  models,  how 
changing  circumstances  alter  the  decisions  reached. 

An  emergency-scenario  DSS  must  possess  certain  charac- 
teristics to  be  useful  to  an  emergency  manager.  The  system 
must  be  portable  to  accompany  the  emergency  manager  to 
disaster  sites.  It  must  contain  sufficient  computer  memory 
to  house  a  database  and  sophisticated  software  programs  used 
to  interpret  the  database  and  provide  simulation  and  opti- 
mization modelling.  The  user  must  have  exclusive  use  of  the 
DSS.    In  an   emergency,   the  manager  must  use  an  instantly 


responsive   system   to   enable  him   to   receive   information 
quickly. 

Present  day  microcomputers  are  very  appropriate  to  house 
such  decision  support  systems.  Unlike  main-frame  computers 
or  minicomputers,  microcomputers  are  fully  portable, 
requiring  only  a  power  source.  With  the  explosive  refine- 
ments in  hardware  production,  microcomputers  now  have  suffi- 
cient available  memory  to  house  sophisticated  databases  to 
store  and  organize  information,  software  modelling  and  opti- 
mization algorithms  to  interpret  information  and  complex 
graphics  packages  to  display  the  interpreted  data  in  forms 
selected  by  the  decision-maker. 

Several  examples  of  microcomputer  use  for  emergency 
decision  support  systems  exist.  Three  will  be  described 
briefly. 

A.   U.S.  COAST  GUARD  SEARCH  AND  RESCUE  PLANNING  ( SARP ) 

Part  of  the  mission  of  the  United  States  Coast  Guard  is 
to  search  for  and  rescue  persons  and  craft  lost  at  sea.  To 
do  this,  the  Coast  Guard  must  identify  the  presumed  position 
of  the  person  or  craft,  called  the  "datum",  and  direct 
search  and  rescue  ( SAR)  teams  to  that  position.  Fixing  the 
datum's  position  on  the  ocean  surface  involves  four  steps 
[Ref.  1]  . 

1.  Determine  drift  forces.  Three  types  of  forces  can  act 
on  a  person  or  craft  to  move  them  over  the  water  s 
surface.  Sea  current  is  the  permanent,  large  scale 
flow  of  the  ocean  waters.  Wind-driven  current  is  the 
current  generated  by  the  wind  acting  upon  the  surface 
of  the  water  for  a  period  of  time.  Leeway  is  the 
movement  of  an  object  through  the  water  caused  by 
local  winds  blowing  against  the  exposed  surface  of  the 
object. 

2.  Determine  vectors.  These  vectors  are  based  on  the 
three  types  of  forces  to  determine  datum  position. 

3.  Determine  error  margin.  Any  possible  error  margin 
must  be  calculated  for  the  vector  determinations  made 
in  step  three. 

4.  Determine  the  search  radius.  A  search  radius  must  be 
calculated  around  the  datum  position  that  will  ensure, 
with  a  better  than  fifty  percent  probability,  that  the 
search  target  is  within  the  search  area. 
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Prior  to  the  early  1970' s,  the  Coast  Guard  performed 
manually  the  four  steps  described  above.  The  current  drift 
forces  were  determined  by  averaging  wind  and  water  speeds 
through  weather  forecasts.  The  vectors  were  determined 
through  calculations.  Error  detection  was  not  performed 
because  such  lengthy  re-calculations  consumed  precious  time. 
The  search  radius  was  determined  through  calculations  and 
statistical  formulas.  The  total  time  required  to  calculate 
the  datum  position  and  search  radius  manually  was  approxi- 
mately forty-five  minutes  to  one  hour  and  required  a  search 
planner  reasonably  familiar  with  the  system. 

In  the  early  1970' s,  the  Coast  Guard  automated  the  four 
steps  on  a  time-shared  main-frame  computer.  To  use  this 
system,  the  search  planner  drafted  a  message  containing  the 
time  of  the  incident,  the  incident  position,  the  desired 
datum  time,  two  error  calculation  numbers  obtained  from  the 
National  SAR  Manual  and  the  type  of  leeway  to  be  considered 
(obtained  from  a  computer  handbook).  The  message  took 
approximately  five  minutes  to  draft  and  was  sent  by  teletype 
to  the  main-frame  computer.  The  SARP  program  reply,  with 
the  datum  position  and  search  radius,  would  be  received  by 
the  search  planner  within  twenty  minutes,  if  no  problems 
arose.  If  the  search  planner  or  the  teletype  operator  typed 
errors  into  the  message,  the  mainframe  computer  would  send 
an  error  message  back  and  the  message  would  be  retran- 
smitted. This  caused  delays  of  up  to  several  hours  since 
the  search  planner  would  not  know  his  message  was  unusable 
until  he  received  the  computer  response.  The  computer 
program  was  inaccessible  when  the  mainframe  computer  was  not 
operating  or  when  the  teletype  circuit  was  broken.  In  this 
case,  the  datum  position  and  search  radius  were  calculated 
manually. 

In  1982,  the  SARP  program  was  installed  in  a  microcom- 
puter.    The   current  microcomputer  version   of   the   SARP 
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program  presents  the  search  planner  with  a  menu-driven 
display  which  prompts  him  for  needed  information.  The 
program  can  calculate  the  datum  position  and  search  radius 
in  approximately  thirty  minutes.  The  search  planner  works 
directly  with  the  system,  without  a  teletype  interface  and 
can  verify  immediately  that  his  input  is  keyed  in  correctly. 
The  system  is  reliable  since  the  microcomputer  is  always 
accessible  to  the  search  planner. 

B.   AMERICAN  RED  CROSS  EMERGENCY  MANAGER  DECISION  AID 

In  a  disaster,  the  Red  Cross  quickly  and  accurately 
assesses  the  physical  severity  of  the  disaster  and  the 
ability  of  people  to  cope  with  their  losses  [ Ref .  2].  The 
Red  Cross  thus  determines  the  level  and  monies  which  must  be 
expended  to  alleviate  the  situation.  To  do  this,  the  Red 
Cross  performs  four  procedures. 

1.  Predisaster  Surveys.  The  Red  Cross  maintains  files  of 
information  gathered  by  periodic  surveys  conducted  by 
local  Red  Cross  chapters.  These  surveys  estimate  the 
value  of  property  as  well  as  facts  about  insurance 
coverage. 

2.  "Windshield  surveys".  Immediately  after  a  disaster, 
Red  Cross  field  teams  assess  and  record  the  extent  and 
nature  of  property  damage. 

3.  Determination  of  disaster  severity.  The  Red  Cross 
emergency  managers  on  site  use  the  windshield 
surveys",  together  with  pre-disaster  information,  to 
determine  the  severity  of  the  disaster  and  the  appro- 
priate resources  that  must  be  brought  to  the  disaster 
site. 

4.  Case   file   preparation.     At   Red  Cross   emergency 
centers,    emergency   managers   use   the   pre-disaster 
surveys,   "windshield  surveys"  and   claims  of  disaster 
victims  to   determine  the  extent  of   disaster  victims 
needs. 

The   Red  Cross   emergency  managers  must  determine   the 

severity  of  the   disaster,   the  resources  necessary   and  the 

fair  resolution  of  victims'  claims   very  quickly.    They  are 

required   to  compare   data  on   pre-disaster  conditions   with 

disaster  reports.     They  must  ensure  that   disaster  victims 

are  fairly  compensated,    but  that  duplicate  claims   are  not 

accepted. 
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When  the  emergency  managers  perform  these  procedures 
manually,  many  problems  arise  which  can  be  attributed  to  a 
lack  of  two  requirements,  which  are  discussed  below. 

1. 

victims'   claims   n   tney  must   manually   r 


Timeliness.  The  managers  cannot  respond  quickly  to 
victims  claims  if  they  must  manually  review  and 
attempt  to  connect  pre-disaster  surveys,  windshield 
surveys"  and  victims   claims. 


2.  Accuracy.  If  expedition  of  claims  processing  becomes 
paramount,  survey  reviews  and  therefore  prevention  of 
duplicate  claims  becomes  harder. 

In  1979,  the  Red  Cross  tested  a  microcomputer-housed  DSS 
in  an  actual  field  incident.  The  database  within  the  DSS 
organized  the  information  gathered  by  pre-disaster  surveys. 
The  information  gathered  by  "windshield  surveys"  was  entered 
into  the  database  by  simple  menu-driven  questionnaires.  The 
emergency  manager  could  then  use  DSS-driven  programs  to 
compare  pre-disaster  conditions  with  disaster  information  to 
determine  disaster  severity  and  the  recovery  resources 
required. 

Case  workers  could  enter  files  for  victims  by  names, 
ensuring  only  one  claim  was  filed  per  family,  and  then 
verify  the  victims'  claims  by  comparison  of  their  claim  with 
pre-disaster  survey  information.  All  this  information  was 
reliable,  available  quickly  and  much  more  accurate  than 
information  gathered  by  manual  methods. 

C.   REGIONAL  EMERGENCY  MEDICAL  ORGANIZATION  (REMO) 

This  organization,  located  in  a  six-county  region  around 
Albany,  New  York,  is  responsible  for  coordination  of  an 
emergency  medical  system  which  provides  the  region  with 
effective  medical  services  in  the  event  of  any  emergency 
situation.  Such  service  includes  allocating  ambulances  in 
situations  where  the  need  for  the  ambulances  exceeds  the 
supply. 

To  allocate  the  ambulances,  the  REMO  dispatcher  uses  a 
DSS  programmed  on  a  microcomputer.  The  DSS  attempts  to 
minimize  total  time  victims  have  to  wait  for  an  ambulance  as 
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well  as  minimize  "bottlenecks"  caused  by  over-allocation  of 
any  ambulance.  The  dispatcher  users  graphic  map  displays 
showing  demand  and  resource  locations.  The  DSS  uses  an 
optimization  model  algorithm  to  calculate  the  optimum  ambu- 
lance use,  given  the  resources  and  demand.  The  dispatcher 
can  input  different  demand  priorities  to  observe  how 
different  ambulance  utilization  and  routes  will  change  the 
optimal  allocation. 

The  ability  to  determine  optimal  allocation  under 
different  circumstances  before  he  dispatches  the  ambulances 
allows  the  dispatcher  to  assign  ambulances  more  effectively 
and  thereby  reduces  some  of  the  job  stress,  and  attendant 
mistakes,  he  might  make  by  manual  determination  of  ambulance 
allocation. 

These  three  examples  illustrate  the  value  of  a  DSS  to 
decision-makers  in  three  areas  critical  to  emergency  deci- 
sions: speed,  accuracy  and  data  manipulation.  The  Coast 
Guard  DSS  provides  information  that  leads  to  quick  assign- 
ment of  rescuers.  Using  their  DSS,  the  Red  Cross  workers 
can  approve  damage  claims  for  disaster  victims  with  much 
greater  faith  in  the  accuracy  of  their  data,  "than  by  manual 
methods.  The  REMO  dispatchers  can  use  their  model  algorithm 
to  interpret  the  raw  data  of  ambulance  and  passenger  posi- 
tions into  optimal  routes,  thereby  eliminating  data  inunda- 
tion of  the  dispatchers. 

As  has  been  discussed,  an  emergency  decision  manager 
faces  three  basic  requirements  in  any  decision  he  makes. 
The  decision  must  be  made  quickly  to  avert  disaster  or 
alleviate  an  emergency.  The  decision  must  be  right,  since 
emergencies  do  not  allow  for  multiple  attempts  to  solve  a 
problem.  The  decision  usually  must  be  backed  by  analysis  of 
data,  which  in  an  emergency  comes  to  the  decision-maker 
quickly  and  in  an  unorganized  fashion.  A  computer-driven 
decision   support   system   can  help   an   emergency  manager 
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immensely  in  several  ways.  It  can  provide  models  of 
possible  results  of  decisions,  allowing  the  decision-  maker 
to  see  the  probable  results  of  his  decisions  before  he  makes 
them.  This  modelling  facility  allows  the  decision-maker  to 
improve  the  chances  his  decision  will  be  accurate.  The  DSS 
can  sort,  interpret  and  present  information  to  the  decision- 
maker in  a  format  he  can  understand.  This  data  handling 
facility  protects  the  decision-maker  from  inundation  by  all 
sorts  of  data,  some  of  which  he  must  know  to  reach  a  deci- 
sion and  some  of  which  is  superfluous  to  the  decision 
process.  Finally,  the  DSS  performs  these  functions  much 
faster  than  possible  by  a  human  staff. 

The  Decision  Support  Systems  described  in  this  chapter 
work  because  they  provide  decision-makers  with  the  facili- 
ties described  above.  As  will  be  seen  in  subsequent  chap- 
ters, the  FAMIS  emergency  manager  will  require  the  same 
types  of  services  to  perform  his  allocation  decisions. 
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II.  INTRODUCTION 

Coping  with  the  consequences  of  a  nuclear  attack  and 
dealing  with  the  aftermath  of  a  natural  disaster  such  as  a 
hurricane  or  earthquake  involve  different  problems, 
resources  and  solution  methods.  All  such  disasters, 
however,  require  reliable  communications  to  allow  people  to 
assess  impact,  make  decisions,  put  appropriate  responses 
into  play,  allocate  needed  resources  effectively  and  restore 
social  stability.  Given  this  country's  dependence  on  tele- 
communications as  a  quick,  reliable  means  of  communication, 
the  establishment  and  maintenance  of  a  reliable  telecommuni- 
cations system  in  the  advent  of  an  emergency  is  vital  for 
recovery  from  the  disaster. 

In  recognition  of  this  need,  the  Federal  Government  has 
empowered  the  National  Security  Council  (NSC)  to  develop 
policy  for  emergency  telecommunications  management  in 
conjunction  with  the  Federal  Communications  Commission 
(FCC).  The  Nationwide  Emergency  Telecommunications  System 
(NETS)  that  will  eventually  be  developed  will  use  existing 
resources  of  the  Public  Switched  Network,  to  provide  commu- 
nications among  many  field  recovery  agents,  who  will  oversee 
regional  survival  and  recovery  actions. 

Since  the  break-up  of  AT&T,  the  Public  Switched  Network 
(PSN)  has  become  controlled  by  many  private  and  public 
companies.  This  thesis  will  not  address  the  issues  of 
policy,  authority,  and  management  which  NCS  must  address  to 
obtain  cooperation  of  the  various  private  companies  and 
government  agencies  required  to  establish  a  viable  NETS. 
Since  this  thesis  is  concerned  with  the  automation  of  a 
certain  decision  aid  tool  for  use  in  the  operation  and 
control  of  the  NETS  system,  a  working,  valid  NETS  will  be 
assumed  to   exist.    The   following  discussion   of  emergency 
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telecommunication  requirements  assumes  the  existence  of  NETS 
and  requires  cooperation  among  agencies. 

The  PSN  refers  to  the  combination  of  assets  established 
by  private,  public  and  government  agencies  which  are  the 
telecommunications  system  for  the  United  States.  These 
assets  include  telephone  lines,  nodes  to  connect  the  lines, 
teletype/digital  switching  facilities  to  direct  communica- 
tion loads,  satellite  communications,  microwave  facilities 
and  many  other  telecommunication  devices  [ Ref .  3].  These 
assets  allow  a  student  in  California  to  call  his  mother  in 
Georgia,  allow  computers  in  New  York  to  "talk"  to  computers 
in  Hawaii  and  permit  the  Department  of  Defense  to  issue 
directives  to  military  bases. 

In  an   emergency,   this  telecommunications   system  would 
form  the  ideal  media  for  emergency  communications  because: 

1.  it  is  already  in  place, 

2.  it  can  access  the  entire  country,  and 

3.  it  is  highly  redundant,  which  means  that  many 
different  communication  routes  exist  between  the  same 
two  points. 

Given  that  NCS  is  empowered  to  manage  this  system  in  an 
emergency,  questions  regarding  the  policy  and  method  of 
allocating  the  resources,  i. e.  the  available  telephone 
lines,  of  this  system  must  be  addressed.  In  an  emergency, 
it  can  be  anticipated  that  many  more  people  will  want  to  use 
available  telecommunication  facilities  than  are  available. 
The  telephone  companies  handle  such  an  overload  on  Mother's 
Day  and  Christmas  by  queueing  calls.  That  is,  the  caller 
gets  a  busy  signal,  or  a  "sorry,  we're  busy"  message,  until 
lines  are  available. 

Such  blind  queueing  will  not  be  a   workable  solution  to 

overload  of   emergency  telecommunications   lines  because   of 

possible: 

1.  low  priority  use.  Such  arbitrary  queueing  might 
prevent  a  caller  with  a  more  valuable  function,  such 
as  delivery  of  hospital  supplies,  from  making  a  call, 
while  allowing  the  college  student,  who  called  first, 
to  see  if  his  mother  is  all  right. 
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2.  insufficient  use.  Unless  controlled,  lines  might  be 
in  heavy  demand  for  certain  periods  and  in  no  demand 
during  other  periods.  Callers  who  could  have 
completed  necessary  calls  at  certain  times  would  be 
unable  to  complete  calls  at  other  times. 

The  problem  of  blind  queueing  would  be  aggravated  by 
loss  of  lines.  Natural  or  nuclear  disasters  could  destroy 
part  of  the  telecommunications  system,  which  is  mostly 
comprised  of  lines  stationed  above  ground. 

An  alternative  to  blind  queueing  is  active  allocation  by 
NCS  managers  of  resources  (telecommunication  lines)  to 
recovery  agants.  As  was  shown  in  the  REMO  example  in  the 
previous  chapter,  such  allocation  decisions  can  be  made  more 
effectively  by  a  manager  with  automated  decision  aids.  In 
recognition  of  this  fact,  NCS  is  currently  developing  the 
Fly-Away  Management  Information  System  (FAMIS). 

A.   FLY-AWAY  MANAGEMENT  INFORMATION  SYSTEM  (FAMIS) 

FAMIS    currently   exists    in   prototype   form   only. 
Installed  on  a  microcomputer,   it  is  a  file-drawer  system  in 
that   it  is   used  solely   for   information  retrieval.     The 
following  information   is  currently   available  to   the  FAMIS 
user. 

1.  A  list  of  primary  and  secondary  points  of  contact  for 
various  government  and  private  agencies. 

2.  Instructions  for  activating  emergency  procedures. 

3.  Graphic  map  depictions  of  the  NETS. 

4.  A  damage  model  which  will  allow  the  user  to  superim- 
pose simulated  damage  on  the  NETS,  to  determine 
projected  remaining  resources. 

5.  A  word  processor,  currently  Wordstar. 

This  thesis  will  discuss  the  possible  characterization 
of  a  Decision  Support  System,  which  is  a  needed  sixth 
feature  of  the  FAMIS  system.  In  determining  the  character- 
istics of  the  FAMIS  DSS,  questions  and  objectives  which  the 
emergency  manager  must  address  through  the  DSS  will  be  exam- 
ined in  Chapter  III.  Information  needed  to  answer  these 
questions  will  be  identified  in  Chapter  IV.    The  necessary 
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computer  literacy  of  the  emergency  manager  will  be  discussed 
in  Chapter  V.  A  possible  adjudication  algorithm  will  be 
analyzed  in  Chapter  VI.  Finally,  the  proposed  DSS  itself 
will  be  presented  in  Chapter  VII. 
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III.  DSS  DESIGN  REQUIREMENTS 

This  chapter  will  explore  the  objectives  the  FAMIS 
manager  will  achieve  through  utilization  of  a  DSS.  Since 
these  objectives  involve  decisions  made  by  the  FAMIS 
manager,  the  decision  process  itself  will  be  briefly 
discussed.   Design  requirements  for  a  DSS  will  be  described. 

A.   DECISIONS  AND  THE  DECISION-MAKING  PROCESS 

Decisions  can  be  defined  as  the  end-products  of 
information-processing.  Any  information-processing  system 
that  yields  the  finished  product,  i. e. ,  the  decision,  can 
therefore  be  considered  to  be  a  decision-making  system.  For 
purposes  of  our  example,  the  FAMIS  manager  will  be  consid- 
ered a  decision-making  system. 

A  structured  decision,  also  called  a  programmable  deci- 
sion, consists  of  three  steps: 

1.  defining  the  problem, 

2.  designing  choices,  and 

3.  choosing  the  best  choice. 

If  any  of  these  steps  cannot  be  described  to  a  computer, 
the  decision  is  considered  unstructured.  That  is,  human 
qualities  of  experience,  association  and  intuition  are 
necessary  to  reach  a  decision;  the  decision  cannot  be 
reached  logically  by  a  computer  alone. 

A  DSS  can  aid  a  human  manager  in  such  decision-making  in 
that  it  can  answer  structured  questions  posed  by  the  manager 
that  aid  him  in  solving  the  unstructured  problem.  A  simple 
example  of  such  a  decision  aid  is  a  pocket  calculator.  By 
itself,  the  calculator  cannot  suggest  answers  to  engineering 
questions,  but  it  can  solve  mathematical  equations  chosen  by 
a  construction  engineer  which  allow  the  engineer  to  then 
decide  where  a  new  dam  should  be  built. 
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A  more  complex  analogy  can  be  drawn  between  a  DSS  and  a 
human  staff.  When  a  manager  with  a  staff  faces  a  problem, 
he  requires  his  staff  to  use  available  statistics,  histor- 
ical data  or  other  information  to  produce  answers  to  ques- 
tions the  manager  then  uses  to  help  him  decide.  The  answers 
such  a  manager  seeks  from  his  staff  are  not  the  direct 
answers  to  the  problem.  Rather,  the  manager's  questions  to 
his  staff  usually  take  the  form  of: 

1.  request  for  retrieval  of  information.  Such  informa- 
tion can  involve  statistical  analysis  of  raw  data  or 
other  such  grouping,   and/or 

2.  request  for  modelling  information.  Such  requests 
usually  take  the  form  of  ad  hoc  questions  and  involve 
projection  of  possible  outcomes  using  historical  data, 
optimization  algorithms  and  data  comparison. 

The  manager  uses  these  answers  to  acquire  some  indica- 
tion of  consequences  of  various  decisions.  He  can  therefore 
make  a  decision  with  more  authority.  Such  staff  support 
differs  from  simple  data  retrieval  because  the  staff  is 
expected  to  interpret  the  raw  data  and  present  to  the 
manager  only  that  information,  in  a  determined  form,  which 
will  aid  the  manager  in  his  decision  process. 

The  staff  therefore  serves  two  functions  for  the 
manager: 

1.  providing  the  manager  with  information  necessary  for 
his  decision,  and 

2.  screening  from  the  manager  extraneous  data,  the  diges- 
tion of  which  would  interfere  with  his 
decision-making. 

A  truly  effective  staff  can  call  upon  enough  varied  analysis 
tools  to  provide  answers  to  the  manager's  varied  questions. 

A  computer-generated  DSS  should  fill  the  same  require- 
ments as  the  staff  for  the  manager.  Using  a  DSS,  a  manager 
should  be  able  to  manipulate  and  selectively  use  information 
to  determine  answers  which  will  enable  him  to  make  intelli- 
gent decisions  for  unstructured  problems  typical  of  the  real 
world. 
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B.   DSS  DESIGN  REQUIREMENTS 
1.   Design  Criteria 

Generally,    decision  support   systems  reflect   four 
design  criteria. 

a.  Representations 

This  means  the  use  of  CRT  tubes  in  conjunction 
with  software  programs  which  will  present  reports,  charts, 
geometric  representations,  etc.  Such  representations  must 
be  constructed  in  a  form  that  is  understandable  to  the 
decision-maker. 

b.  Support 

Support  of  intelligence,  design  and  choice 
activities.  This  includes  operations  like  comparing  current 
status  with  goals  or  standards,  exception  reporting  and 
preliminary  calculations. 

c.  Memory  Aids 

This  includes  English-like  Data  Base  Management 
Systems  (DBMS)  which  allow  flexible,  interactive  access  to 
data.  The  decision-maker  requests  information  from  the  DBMS 
in  English.  The  DBMS  then  constructs  the  software  programs 
necessary  to  retrieve  and  organize  the  information. 

d.  Decision  Maker  Control 

This  means  man-machine  interaction,  online  and 
in  real-time  without  the  intermediary  of  programmers.  Such 
immediate  interaction  between  the  DSS  and  the  decision-maker 
is  vital  for  three  reasons.  First,  such  interaction  allows 
the  decision-maker  to  see  his  input,  assuring  it  is  entered 
error-free.  Second,  an  interactive  DSS  allows  a  decision- 
maker to  ferret  out  specific  information  from  a  large  amount 
of  unassociated  data  quickly.  Third,  the  decision-maker  can 
observe  answers  to  his  questions  immediately.  Such  imme- 
diate response  is  especially  vital  in  an  emergency,  where 
the  decision-maker  must  have  projected  result  information 
quickly. 
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2.   Requirements 

To  support  these   criteria,   a  DSS  must   fulfill  the 
following  requirements. 

a.  Data  Management  Capability 

A  data  base  management  system  (DBMS)  must  exist 
as  a  software  interface  between  the  decision-maker  and  his 
database.  A  database  is  a  collection  of  data,  also  called 
information,  which  is  organized  logically  into  a  system  of 
some  sort.  The  DBMS  software  programs  accept  requests  from 
the  decision-maker,  in  English,  for  information.  The  DBMS 
then  retrieves  the  information,  which  may  be  stored  logic- 
ally in  many  disparate  physical  locations  in  computer 
memory.  The  DBMS  then  organizes,  arranges  and  presents  the 
information  to  the  decision-maker,  in  a  form  specified  by 
the  decision-maker.  For  instance,  a  manager  might  request  a 
list  of  all  telephone  users  who  require  a  dedicated  phone 
line,  and  he  may  wish  to  see  this  information  in  a  table, 
arranged  in  ascending  order  by  last  name.  A  good  DBMS  will 
take  the  English  request  and  utilize  the  necessary  software, 
internal  to  itself,  to  produce  the  table.  At  the  manager's 
request,  the  DBMS  can  present  the  same  information  arranged 
by  location  of  the  user. 

b.  Analytical  Capability 

As  mentioned  previously,  a  DSS  must  be  able  to 
manipulate  data,  as  well  as  present  it.  Many  kinds  of  anal- 
ysis tools  are  used  by  decision  support  systems  and  these 
tools  vary  in  complexity,  depending  on  the  depth  of  analysis 
required  and  the  breadth  of  data  to  be  considered.  A 
partial  list  of  such  analysis  tools  could  include  [ Ref .  4], 

(1)  Data  Analysis.  In  data  analysis, 
historical  data  is  subjected  to  statistical  analysis  and 
other  projection  formulae  to  determine  trends,  to  project 
future  outcomes  and  to  determine  present  status.  Many 
businesses  use   such  analysis  to   predict  sales   trends,   to 
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help  compile  five-year  budget  plans  and  other  activities 
which  require  analysis  of  historical  data.  A  FAMIS  manager 
might  use  this  tool  to  determine  present  capacity  of  lines 
or  to  compare  priorities  of  competing  users. 

(2)  Simulation.  In  simulation  models, 
projection  of  outcome  is  based  on  algorithms  which  involve 
data.  Such  models  are  different  from  data  analysis.  In 
data  analysis,  the  historical  data  and  all  factors  which  act 
on  the  data,  i. e.  interest  rates,  are  known.  In  simulation 
modelling,  some  of  the  parameters  which  act  on  the  data  are 
unknown  or  assumed.  A  factor  of  uncertainty  is  thereby 
introduced.  Representational  models  are  particularly 
valuable  when  answering  ad  hoc  kinds  of  questions,  where 
some  circumstances  must  be  assumed  to  project  an  answer. 
The  FAMIS  manager  could  use  a  tool  of  this  type  to  simulate 
reallocation  of  resources  to  accommodate  a  coast-to-coast 
line  connection  for  two  high-priority  users. 

(3)  Optimization  Models.  These  models 
describe  situations  mathematically  as  complicated  puzzles 
whose  solution  is  maximization  or  minimization  of  a 
particular  goal.  Optimal  use  of  FAMIS  resources,  subject  to 
certain  constraints  such  as  minimization  of  nodes  involved, 
might  be  a  potential  problem  which  a  DSS  would  employ  an 
optimization  model  to  solve. 

(4)  Suggestion  Models.  These  models  are  more 
structured  than  optimization  models  and  whose  output  is 
pretty  much  the  answer  to  the  decision-maker's  problem. 
Such  models  are  called  expert  systems  and,  while  applicable 
to  many  areas,  are  inappropriate  for  application  in  the 
FAMIS  system.  Suggestion  models  are  designed  to  suggest 
actions  based  on  a  pre-determined  set  of  criteria  or 
conditions.  If  these  criteria  change,  such  as  changing  the 
condition  mode  of  the  FAMIS  system  from  survival  to 
recovery,   the  suggestion  model  must  be  altered   to  produce 
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new  suggestions  based  on  the  changed  goal  of  recovery.  It 
is  considered  more  feasible  in  the  FAMIS  system  to  allow  the 
manager  to  assume  this  role,  supported  by  optimization, 
simulation  and  data  analysis  models  as  described  above. 

c.  Transportability 

It  is  unrealistic  to  presuppose  that  an  emer- 
gency decision-maker  will  be  able  to  remain  at  a  particular 
location  during  an  emergency.  Available  communications 
resources,  facilities  and  other  concerns  might  force  such  a 
manager  to  be  mobile.  A  DSS  used  to  support  such  a  manager 
must  be  portable.  The  potential  problems  of  interfacing 
with  a  stationary  mainframe  computer  were  illustrated  in  the 
Coast  Guard  SARP  program  example. 

d.  Reliability 

DSS  reliability  will  be  of  two  types:  reli- 
ability of  the  interface  between  the  manager  and  the  system, 
and  reliability  of  the  information  passed  between  the 
manager  and  the  DSS.  Reliability  of  the  interface,  that  is 
the  percentage  of  time  the  manager  can  use  the  DSS,  will  be 
best  served  by  having  the  decision-maker  as  the  sole  user  of 
the  DSS.  Reliability  of  the  information  exchanged  can  be 
best  assured  by  an  interactive  system,  where  the  manager  can 
instantly  check  that  he  enters  the  proper  data  and  can 
instantly  see  the  actual  response  from  the  DSS  display. 

e.  Flexibility 

It  is  impossible  to  determine  in  advance  all 
questions  a  manager  will  be  required  to  ask  a  DSS  to  accumu- 
late enough  pertinent  information  to  make  a  decision. 
Therefore,  a  DSS  must  possess  the  flexibility  in  its  soft- 
ware to  accept  new  questions  formulated  by  the  manager.  For 
instance,  a  menu-driven  DSS  which  will  only  answer  three 
pre-determined  optimization  questions  will  be  of  limited  use 
if  new  circumstances  arise.  Such  flexibility  could  possibly 
be  built  into  a  DSS  by: 

a)   generalization  of  the  model/analysis  programs 
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b)  incorporation  of  a  model-building  ability  within  the 
DSS.  Such  a  model-building  program  would  construct 
new  algorithms  for  models  as  the  manager  requests  new 
analysis  approaches. 

f.   Maintainability 

Maintainability,  particularly  of  the  database, 
is  vital.  A  DSS  used  by  the  FAMIS  system  will  be  only  as 
useful  as  its  data  is  current  and  accurate.  Optimization  of 
user  use  of  communication  lines  by  priority  will  be  impos- 
sible if  some  of  the  users  no  longer  exist  or  if  the  lines 
specified  have  been  changed  prior  to  the  emergency. 

As  discussed  above,  these  requirements  would  be 
essential  in  a  DSS  associated  with  the  FAMIS  system.  The 
requirements  of  portability  and  reliability  would  be  best 
satisfied  if  the  DSS  resided  in  a  microcomputer.  The  data- 
base on  a  microcomputer  could  be  updated  periodically  by 
floppy  disk  or  by  connection  through  a  modem,  prior  to  emer- 
gency conditions,  to  ensure  information  is  current.  Most 
analytical  tools,  display  packages  and  database  management 
systems  can  operate  in  a  modern  microcomputer. 

The  actual  components  of  a  generic  DSS, 
including  design  specification,  program  description,  data- 
base types  and  hardware/software  implementation  will  not  be 
discussed  in  this  thesis.  The  FAMIS  system  will  serve  as 
determinant  of  questions  the  manager  and  the  DSS  must 
address,  as  well  as  for  description  of  data  formats  used  for 
application  of  the  DSS.  These  issues  are  considered  in  the 
following  chapter. 
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IV.  QUESTIONS  ADDRESSED  BY  THE  FAMIS  MANAGER  AND  THE  DSS 

Within  the  FAMIS  scenario,  the  manager  must  decide  on 
the  allocation  of  remaining  scarce  telecommunication 
resources  to  a  competing  set  of  qualified  recovery  agents 
who  need  those  assets  to  solve  specific  problems  associated 
with  the  emergency.  As  described  in  Chapter  II,  all  avail- 
able private  and  public  telecommunications  links  would  be 
combined  to  form  an  emergency  communication  network  in  the 
advent  of  a  disaster.  The  Public  Switched  Network  (PSN), 
which  is  the  major  telephone  communications  system  in  the 
country,  is  a  vast  complex  of  local  offices,  trunks  and 
switching  nodes.  Given  that  it  is  feasible  to  reconstitute 
an  emergency  network  from  the  surviving  nodes  and  links,  if 
the  remaining  available  resources  exceed  the  requirements  of 
the  users,  the  manager's  allocation  decision  is  uncompli- 
cated and  does  not  require  the  aid  of  a  DSS. 

However,  if  the  recovery  agents'  requirements  exceed 
available  remaining  communication  resources,  -as  is  expected 
in  the  FAMIS  system,  then  the  manager  must  answer  several 
questions  associated  with  resource  allocation. 

These  questions  can  be  grouped  into  four  broad 
categories: 

1.  What  problems  associated  with  the  emergency  need  to  be 
solved? 

2.  What  recovery  agents  are  out  there  to  manage  the 
required  resources  necessary  to  help  solve  the 
problems? 

3.  What  communication  resources  remain? 

4.  What  communication  resources  are  needed  to  help  which 
agents  mobilize  remaining  resources  to  help  solve 
emergency  problems? 

This  chapter  will  discuss  these  four   categories.    The 

categories   themselves   will   be    discussed   and  questions 

addressed  by   the  DSS  will   be  identified  within  applicable 
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categories.  These  questions  will  be  examined  and  a  neces- 
sary flow  of  information  will  be  established  which  will  be 
shown  to  culminate  in  resolution  of  allocation  questions. 

A.   WHAT  PROBLEMS  NEED  TO  BE  SOLVED? 

In  a  national  or  regional  disaster,  the  problems  an 
emergency  manager  faces  can  be  expressed  in  terms  of  mobili- 
zation. Mobilization  is  the  process  of  marshalling 
resources  to  support  a  response  to  an  emergency.  [ Ref .  5] 
Resources  can  include  food,  medical  supplies,  troops, 
building  supplies  and  whatever  else  is  needed  to  survive  and 
recover  from  a  disaster.  Several  categories  of  mobilization 
exist,  dependent  on  the  types  of  resources  being  mobilized 
and/or  the  application  of  these  resources. 

•  Military  mobilization  -  deployment  of  manpower,  weapons 
and  tactical  information. 

•  Industrial  mobilization  -  marshalling  the 
manufacturers/producers  to  supply  goods  and  services. 

•  Economic  mobilization  -  marshalling  money  and  credit  to 
fund  the  mobilization  effort. 

•  Human  Resources  mobilization  -  marshalling  people  to 
perform  needed  work  toward  survival  and  recovery. 

•  Infrastructure  mobilization  -  marshalling  such  systems 
as  transportation,  energy,  communications,  construction 
and   agriculture   to   support    survival   and   recovery 

efforts. 

•  Civil  Defense  mobilization  -  marshalling  forces  to 
provide  protection  and  recovery  for  people  and  industry 
from  nuclear  attack. 

•  Governmental  mobilization  -  marshalling  resources  of 
local,  state  and  federal  governments  to  respond  to  and 
recover  from  the  disaster/emergency. 

In  an  emergency  or  disaster,  regional  recovery  agents 
will  manage  these  mobilization  steps  within  their  own 
geographic  areas.  The  FAMIS  system  exists  to  allocate 
scarce  remaining  telecommunications  resources  to  these 
recovery  agents  to  enable  the  agents  to  direct  mobilization. 

Thus,  the  crucial  first  problem  the  FAMIS  manager  must 
address  concerns  identifying  mobilization  requirements.  The 
category  of  mobilization  needed  will  depend  on   the  type  of 
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emergency/disaster.  Logically,  this  information  will  come 
to  the  FAMIS  manager  from  regional  recovery  agents  or  from 
other  sources  who  have  current  information  about  the  type 
and  scope  of  the  emergency  or  disaster.  Since  the  FAMIS 
manager  needs  this  information  before  he  can  allocate  NETS 
resources,  it  is  logical  to  assume  that  this  information 
must  reach  the  manager  via  a  more  dependable  communication 
medium  than  the  telephone.  A  high-frequency  radio  network 
is  a  viable  possible  communication  medium  for  transmission 
of  this  initial  information.  Once  the  NETS  is  established, 
the  FAMIS  manager  could  also  receive  mobilization  require- 
ment updates  from  recovery  agents  via  NETS  calls. 

Once  the  mobilization  problems  have  been  identified,  the 
FAMIS  manager  can  begin  to  solve  these  problems  by  deter- 
mining answers  to  the  questions  in  the  remaining  three 
categories  listed  in  the  introduction  to  this  chapter  and 
discussed  below. 

B.   WHAT   RECOVERY   AGENTS   ARE   OUT   THERE   TO   MANAGE   THL 
REQUIRED  RESOURCES? 

To  answer  this  question,  the  FAMIS  manager  will  elicit 
information  from  the  FAMIS  DSS,  as  well  as  real-time  infor- 
mation from  his  high-frequency  radio  network  and/or  NETS 
updates. 

1.   What  is  the  current  mode? 

Allocation  of  communications  resources  will  be 
dependent  on  the  user's  importance  relative  to  the  current 
mode  or  goal.  If  the  emergency  is  in  a  survival  mode,  then 
recovery  agents  whose  functions  involve  procurement  and 
distribution  of  food,  hospital  provisions  and  other  imme- 
diate needs  might  receive  highest  priority  to  use  communica- 
tion resources.  If  the  emergency  mode  has  changed  to 
recovery,  then  recovery  agents  essential  to  re-establishment 
of  non-essential  services  might  receive  higher  allocation 
priority.    The   need  to   establish  an   emergency  government 
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might  require  priority  use  of   resources  by  users  who  were 

unimportant  for  survival  mode  operations.   The  FAMIS  manager 

will   determine  the   current  mode   via  high-frequency   radio 

network  and/or  NETS  updates  from   recovery  agents   or  other 

field  officials. 

2.   What   recovery    agents   are   needed   to   mobilize 
resources  for" the  current  mode? 

The  DSS  will  obtain  the  number  and  type  of  remaining 
recovery  agents  from  updates  from  the  FAMIS  manager  or 
through  disaster  modelling.  The  communication  requirements 
of  the  recovery  agents  will  have  been  determined  before  the 
disaster  took  place  and  will  be  part  of  the  FAMIS  database. 

The  following  information  has  been  collected  for 
each  recovery  agent: 

1.  FACILITY  TYPE/IDENTIFICATION.  This  includes  the  type 
of  facility  (e.g. ,  C2  facility,  field  office,  emer- 
gency operations  center,  warehouse)  and  any  identi- 
fying name  or  number  that  be  helpful  in  distinquishing 
it  from  other  facilities.  These  facilities  are  those 
that  are  essential  in  the  performance  of  the  listed 
functions. 

2.  FUNCTION  PERFORMED.  This  includes  the  number  of  func- 
tion(s)  that  would  take  place  at  the  facility. 

3.  LOCATION.  The  name  of  the  nearest  city  or  town  and 
state. 

4.  LONGITUDE/LATITUDE.  This  information  would  fix  the 
facility  on  a  graphics  map. 

5.  NUMBER  OF  PEOPLE  REQUIRING  COMMUNICATIONS  AT  THE 
FACILITY  LOCATION.  This  would  identify  people  who 
would  perform  essential  functions. 

6.  TYPE  OF  VOICE  COMMUNICATIONS  NEEDED.  Types  include 
switched,  which  refers  to  standard  switched  telephone 
requirements  including  data  needs  that  can  be  met 
using  a  dial-up  line  or  a  modem,  and  private  point-to- 

Eoint,  which  refers  to  private  line  voice  systems 
etween  specified  locations,  used  for  security  trans- 
missions. For  each  communications  requirement,  the 
number  of  lines  needed,  the  average  number  of  hours 
per  day  the  telephone  would  be  in  use  to  provide  the 
essential  function  and  security  requirements  would  be 
listed. 

7.  DEDICATED  DATA  REQUIREMENTS.  This  refers  to  the 
number  of  dedicated,  non  dial-up  data  communications 
circuits  needed,  plus  any  security  requirements  for 
these  lines. 

8.  OTHER  SPECIAL  NEEDS. 

9.  PRIORITY.  This  refers  to  the  relative  priority  of  the 
locations  listed.     Notice  that   different  priorities 
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can  apply  to  a  user  under  different  allocation  goals. 
The  DSS  might  be  required  to  assign  several  priorities 
to  each  user,   and  select   the  priority  appropriate  to 
the  allocation   goal  of  survival,   recovery   or  estab- 
lishment of  government. 

The  DSS  would  retrieve  these  facts,  encoded  in  the 
database  for  each  recovery  agent,  to  determine  their  mobili- 
zation task,  communication  requirements  and,  under  the 
current  condition  mode,  priorities  to  use  remaining  communi- 
cation resources. 

3.   Of  these  qualified  recovery   agents,   how  many  still 
exist? 

It  can  be  assumed  that,  in  any  disaster,  a  subset  of 
all  recovery  agents  will  be  destroyed,  incapacitated  or 
otherwise  rendered  ineffective.  To  determine  accurately  how 
many  recovery  agents  actually  remain,  the  FAMIS  manager  will 
be  required  to  augment  and  modify  the  historical  recovery 
agent  data  he  will  receive  from  the  FAMIS  DSS.  His  high- 
frequency  radio  link  or  contacts  he  can  make  via  the  NETS 
are  means  of  providing  this  information.  An  additional 
source  for  projection  of  recovery  agent  losses  could  be 
input  from  the  FAMIS  disaster  model,  which  would  indicate 
locations  affected  by  disaster.  Recovery  agents  in  these 
locations  could  be  assumed  destroyed  for  communication  allo- 
cation purposes,  subject  to  confirmation  by  high-frequency 
radio  or  NETS  link.  The  FAMIS  manager  must  then  input  the 
corrected  recovery  agent  information  to  the  DSS  database  to 
maintain  accuracy.  Such  accuracy  regarding  recovery  agent 
information  will  become  vital  when  the  FAMIS  DSS  is  asked  to 
optimize  allocation  of  communication  resources. 

At  this  point,  the  FAMIS  manager  will  have  identi- 
fied the  mobilization  problems  caused  by  the  disaster  and  he 
will  have  identified,  through  DSS  retrieval  of  information 
coupled  with  high-frequency  radio  updates,  the  qualified 
recovery  agents  who  currently  exist  to  solve  the  mobiliza- 
tion problems. 
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C.   WHAT  COMMUNICATION  RESOURCES  REMAIN? 

The  FAMIS  manager  must  next  determine  the  status  of  the 
existing  communication  network,  over  which  he  will  allocate 
recovery  agent  communication  use.  To  determine  current 
network. status,  the  FAMIS  manager  will  retrieve  answers  to 
the  following  questions  from  the  FAMIS  DSS. 

1.  What  is  the  normal  network  schema? 

The  DSS  will  use  database  files  to  determine  the 
normal  network  of  communication  lines  and  nodes. 

2.  What  resources  ( communication  lines ,  nodes)  remain? 
Using  a   disaster  model,   plus   casualty  information 

fed  in  by  the  FAMIS  manager,  the  DSS  will  then  project  the 
percentage  and  locality  of  lost  communications  to  determine 
what  resources  remain. 

3.  Do  these  nodes  connect  locally/nationally? 

The  DSS  must  then  use  historical  database  informa- 
tion to  determine  if  surviving  nodes  connect  to  form  a 
local,  regional  or  national  network. 

4.  I_s  there  connectivity? 

Once  this  information  is  determined,  the  DSS  can 
project  the  degree  of  connectivity,  together -with  a  graphic 
map  display  showing  the  route(s)  of  connectivity,  to  the 
FAMIS  manager.  The  manager  can  alter  this  graphic  display 
to  reflect  new  connectivity  information  by  asking  the  FAMIS 
DSS  to  compare  original  connectivity  data  with  updates 
received  via  the  high-frequency  radio  network  or  NETS. 
Also,  as  discussed  in  Chapter  II,  the  presence  and  degree  of 
connectivity  must  be  updated  as  further  damage  is  sustained 
by  the  network.  The  DSS  could  automatically  check  the 
status  of  the  networks  periodically  or  at  the  update  request 
of  the  FAMIS  manager. 

5.  What   is  the   capacity  and   throughput  of   remaining 
line's? 

The  capacity   and  throughput  of   communication  lines 

are   important  when   considering   the   lines'   ability   to 
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accommodate  a  set  of  users.  Once  the  existence  of  remaining 
communications  lines  has  been  established,  the  DSS  can 
retrieve  their  capacity  and  throughput  figures  from  the 
database.  The  FAMIS  manager  would  update  these  figures  if 
so  indicated  by  recovery  agent  feedback. 

6.  What   degree   of   reliability    of   remaining  paths 
exists? 

The  reliability  of  remaining  paths  will  be  deter- 
mined by  the  disaster  model  projection  of  damage,  plus  input 
to  the  manager  from  recovery  agents  who  are  utilizing  the 
particular  path. 

7.  How  survivable  are  the  remaining  paths? 
Survivability  of  the  particular   path  will  depend  on 

projected  future  damage,  plus  historical  data  about  the 
path.  For  instance,  if  the  path  is  established  via  satel- 
lite, then  the  type  of  damage,  i. e.  earthquake,  will  deter- 
mine if  the  satellite,  and  therefore  the  communication  path, 
will  survive. 

By  using  the  DSS  capabilities  of  data  retrieval  and 
comparative  analysis,  the  FAMIS  manager  will  now  know  the 
current  status  of  the  emergency  communication  network. 
Using  that  information,  plus  identification  of  the  mobiliza- 
tion problems  and  available  recovery  agents  to  solve  those 
problems,  the  FAMIS  manager  can  now  address  the  fourth 
category  of  questions. 

D.   ALLOCATION  DETERMINATION 

What  communication  resources  are  needed  to  help  which 
agents  use  emergency  resources  to  help  solve  problems? 

Applying  an  adjudication  algorithm  to  the  information 
discussed  in  the  three  previous  sections,  a  DSS  can  deter- 
mine optimum  allocation  of  existing  communication  resources 
in  a  number  of  ways.  This  section  will  explore  some  of  the 
possible  ways  in  which  allocation  configurations  can  be 
made. 
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1.  I_s   there   alternate  routing?     (Do   remaina   lines 
connect  in  more  than  one  way? ) 

Given   that  any  node   will   connect  more   than   two 

lines,   the  possibility  exists   that  connections  between  any 

two  points  (recovery   agents)   can  be  accomplished  via  more 

than  one   route.    The  DSS   must  establish  the   existence  of 

alternate  routing  because  such  alternatives  may   affect  the 

manner  of   allocation,   as  well   as  establish   the  potential 

scope  of   the  network.    The   DSS  could  use   an  optimization 

algorithm  applied  to  existing  lines  to  identify  all  possible 

paths  connecting  all  points  (recovery  agents). 

2.  How  can  number  of  users  on  the  system  be  maximized? 
Two  allocation   issues  become  apparent  in   the  FAMIS 

example:  user  priority  and  utilization  time.  The  DSS  will 
retrieve  the  current  allocation  goal  from  the  manager.  This 
goal  will  determine  which  type  of  priority  will  be  associ- 
ated with  NETS  users. 

3.  How   can   percent   of  time   paths   are   utilized   be 
maximized? 

The  DSS   must  also  consider  time   constraints.    For 

example,   a  higher-priority  user  who   requires  ten  hours  use 

per  day  might  represent   less  effective   use  "of   the  system 

than  four  lower-priority  users  who  all  together  require  only 

four  hours  use  time  per  day. 

4.  How  can  priority  use  on  the  system  be  maximized? 
Given  the   dual  allocation   constraints  of  priority 

and  time,  the  DSS  will  probably  provide  the  manager  with 
possible  resource  allocation  based  on  priority  and  time. 
The  DSS  will  retrieve  time  requirements  and  priority  infor- 
mation for  recovery  agents  from  its  database  and  project 
combinations  of  recovery  agent  use  to  optimize  priority  use 
or  percent  of  time  the  NETS  is  used. 

5.  How   can   the   most  reliable   network  between   long 
distances  be  established? 

The  manager  could   then  invoke  further  ad  hoc  ques- 
tions to  observe   the  results  of  further   tradeoffs.    It  is 
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important  that  the  manager,  instead  of  the  DSS,  effect  these 
tradeoff   questions  to   arrive  at   a  compromise   allocation. 
The  manager,  not  the  DSS,   is  the  decision-maker  and  he  must 
be  able   to  consider  the   projected  results  of   many  options 
before  arriving  at,  in  his  judgement,  the  best  decision. 

6.  I_s  congestion  possible? 

Congestion  of  traffic  flow  over  the  network  is  a 
consideration  the  DSS  must  address  in  allocating  communica- 
tion resources.  Congestion  can  occur  when  communication 
lines  into  a  node  contain  more  "traffic"  than  the  node  can 
direct  on  to  other  lines.  Such  congestion  could  easily  take 
place  if  the  DSS  concerns  itself  solely  with  maximization  of 
the  number  of  users  of  the  FAMIS  system,  without  considering 
even  distribution  of  that  user  load  over  available  nodes. 
Depending  on  the  geographic  concentration  of  users,  some 
nodes  of  the  system  might  be  overloaded  while  others  are 
hardly  used,  unless  distribution  of  the  user  load  is 
considered. 

7.  I_f  possible,  how  can  congestion  be  resolved? 

The  DSS  must  have  an  analysis  tool  that  will  examine 
projected  allocations,  compare  recovery  agent  requirements 
with  line  throughput  and  determine  the  possibility  of 
congestion.  Should  congestion  pass  a  critical  probability 
point,  the  DSS  must  notify  the  FAMIS  manager  and  propose 
alternate  allocations  to  ease  the  congestion.  Given  the 
establishment  of  all  alternate  routing  described  above,  the 
DSS  could  reallocate  communication  line  use  using  an  opti- 
mization algorithm,  subject  to  constraints  against  using 
congested  routes. 

Once  the  FAMIS  manager  has  obtained  answers  to  the 
questions  described  above,  he  can  provide  solutions  to  the 
mobilization  problems  identified.  Circumstances  can  change 
quickly  in  an  emergency,  however,  and  the  FAMIS  manager  must 
be  able  to  obtain  new  answers  to  any  and  all  these  questions 
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if  conditions  change.   The  following  questions  fall  into  one 

of  the   four  categories  of  questions  discussed   above,   but 

they  are   mentioned  here   becuase  they  will  be   prompted  by 

changes  in  the  emergency  environment. 

8.   When  do   conditions  change   sufficiently  to   warrant 
reallocation? 

Questions   which  might  be   addressed   to   determine 

condition  changes  include: 

•  Is  the  condition  mode  different?    (survival,  recovery, 
etc.  ) 

•  Have  resources  changed? 

•  Have  users  changed? 

Allocation  priorities  might  change  as  the  allocation  goals 
change,  as  further  damage  to  the  network  results  in  fewer 
available  communication  resources  or  even  as  recovery  agents 
complete  their  calls  and  no  longer  need  the  communications 
resource.  The  DSS  would  have  to  recognize  a  valid  condi- 
tion of  change  and  then  examine  qualified  recovery  agents  to 
determine  if  their  level  of  use  priority  changes.  If  so, 
new  optimization  algorithms  might  be  required. 

Additionally,  the  manager  might  decide  to  ask  for 
the  outcome  of  different  methods  of  allocation,  for  which 
the  DSS  has  no  programmed  algorithm.  In  these  cases,  the 
DSS  might  be  required  to  have  the  capability  to  build  algo- 
rithms to  suit  such  one-of-a-kind  questions. 

By  answering  the  categories  of  questions  discussed 
in  this  chapter,  the  FAMIS  manager  can  meet  his  objective  of 
effecting  mobilization  of  resources  by  recovery  agents 
through  allocation  of  communication  resources  to  these 
recovery  agents.  The  questions  discussed  in  this  chapter 
are  representative  of  the  types  of  questions  for  which  data 
must  be  amassed  and  for  which  modelling  programs  and  other 
analysis  programs  must  be  prepared. 
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V.  THE  FAMIS  DATABASES 

The  previous  chapter  presented  questions  the  FAMIS 
manager  and  the  DSS  must  address.  This  chapter  will  discuss 
possible  database  types  and  update  methods. 

Data  can  be  defined  as  facts,  which  are  combined  to 
provide  information  about  something.  Much  of  the  data  the 
FAMIS  system  will  use  has  already  een  defined.  Recovery 
agent  information  required  might  include: 

location  (latitude  and  longitude) 

telephone  number 

type  of  user  (his  function) 

priority  of  user  (may  be  several   entries,   based   on 
different  condition  modes) 

type  of  resource  required 

duration  of  resource  requirement 

name  or  code  of  user 

Resource  Information  might  include: 

location  (latitude  and  longitude) 

category   of   resource  (   telephone   line,    microwave, 
satellite  relay) 

type   of   resource  (full-duplex,    private,    switched, 
secure,  etc.  ) 

Other  information  might  be  needed,  depending  on  the 
types  of  decisions  the  FAMIS  manager  has  to  make. 

Data  arranged  in  an  organized  form  is  called  a  database. 
A  card  file  can  be  a  database,  as  can  a  printed  list  of 
names  or  facts  stored  in  the  human  brain.  For  purposes  of 
this  thesis,  a  database  will  be  defined  as  data  arranged  in 
a  logical  form  and  stored  in  a  computer  memory.  Two 
distinct  databases  for  use  with  the  FAMIS  DSS  can  be 
discerned  from  the  data  required.  One  of  these  databases 
will  contain  recovery  agent  information  and  one  will  contain 
communication  resource   information.    Other   FAMIS  database 
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groups  may  be  identifed  later,  but  the  following  discussion 
of  database  types  and  update  procedures  will  apply  to  those 
databases  as  well  as  to  the  two  databases  identified. 

The  type  of  database  is  determined  by  its  data  model, 
which  can  be  defined  as  the  philosophy  of  relations  and 
attributes  of  relations  between  data  in  the  database.  Many 
types  of  databases  exist  and  four  types  will  be  identified 
and  compared  to  determine  a  suitable  database  type  for  FAMIS 
application. 

A.   HIERARCHICAL  DATABASE 

A  hierarchical  database  can  be  described  as  one  in  which 
all  the  data  is  arranged  by  following  one  logical  rule.  In 
a  computer,  a  hierarchical  database  is  arranged  so  that  each 
bit  of  data  has  a  logical  pointer  which  points  to  another 
piece  of  data.  The  telephone  directory,  which  lists  all 
information  alphabetically  by  the  last  name  of  the  indi- 
vidual or  organization,  is  an  example  of  a  hierarchical 
database  system.  Such  a  database  is  useful  only  if  the  data 
requested,  i. e. ,  an  address,  can  be  tied  to  a  last  name. 
Using  the  telephone  directory,  it  is  impossible  to  ask  for 
"John's  address"  or  to  ask  "Who  lives  at  35  Fremont 
Street?".  Such  questions  cannot  be  answered  because  the 
telephone  directory  is  not  designed  to  allow  retrieval  of 
information  by  any  other  means  than  by  last  name.  The  last 
name  is  the  "key"  which  unlocks  the  information  in  this 
hierarchical  database. 

Clearly,  such  a  rigid  database  arrangement  will  be 
insufficient  to  meet  the  information  needs  of  the  FAMIS 
system.  For  example,  to  answer  the  question  of  what 
resources  remain,  the  DSS  must  identify  resources  using 
their  location  key.  The  location  can  then  be  compared  with 
the  disaster  model  results  to  determine  which  communication 
lines  remain.  To  allocate  these  resources,  the  manager  may 
wish  to  know  how  many  lines   of  a  certain  type  exist  between 
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two  points,  such  as  secure  lines,  which  can  handle  the  calls 
of  a  certain  user.  To  obtain  that  information,  the  DSS  must 
identify  resources  by  their  type  key.  By  considering  other 
questions  the  DSS  must  use  resource  information  to  handle, 
it  can  be  seen  that  the  DSS  must  be  able  to  access  the  data 
in  a  database  using  many  different  keys,  grouping  the  data 
in  many  different  ways  to  obtain  the  information  needed  by 
the  FAMIS  manager.  This  requirement  eliminates  a  simple 
hierarchical  database  as  unsuitable  for  FAMIS  application. 

A  hierarchical  database  could  be  built  in  a  way  that 
allows  access  of  data  by  many  different  keys  by  producing 
separate  lists  of  the  same  data  grouped  differently.  To 
continue  the  telephone  directory  analogy,  the  directory 
would  contain  entries  for  each  person  listed  by  last  name  in 
one  section,  by  first  name  in  a  second  section,  by  address 
in  a  third  section  and  so  on.  The  obvious  result  of  such 
redundancy  would  be  a  very  large  telephone  directory.  If 
FAMIS  data  is  organized  this  way,  much  more  computer  memory 
storage  will  be  necessary  to  contain  all  the  redundant  data. 
Retrieval  of  that  data  will  be  slow  since  most  computers 
retrieve  information  using  some  form  of  a  sequential  search. 
To  illustrate  sequential  search,  we  continue  with  our 
analogy.  A  person  using  sequential  search  would  look  first 
through  the  last  name  and  first  name  sections  and  then  the 
address  section  to  determine  who  lives  at  75  Rock  Plaza,  if 
the  data  is  organized  in  that  order.  Such  a  search  will 
waste  a  great  deal  of  time  looking  through  the  two  unneeded 
sections  which  preceed  the  address  section. 

B.   RELATIONAL  DATABASE 

Such  storage  space  and  retrieval  problems  can  be 
relieved  considerably  by  use  of  a  second  type  of  database 
called  relational  database.  A  relational  database  can  be 
described  as  one  in  which  all  data  is  stored  physically  only 
once,   but   can  be  accessed   logically  many   different  ways. 


39 


Such  access  can  be  accomplished  because  indexes  are  created 
within  the  relational  DBMS  which  relate  the  bits  of  data  in 
several  ways.  A  relational  database  telephone  directory 
would  list  each  person  only  once,  but  would  have  indexes 
associated  with  each  name  which  would  logically 
re-categorize  that  person  by  last  name,  first  name,  address 
or  by  other  characteristics.  In  FAMIS,  a  relational  data- 
base would  allow  the  DSS  to  retrieve  information  regarding 
remaining  resources  grouped  in  many  different  logical 
categories.  This  flexibility  in  data  retrieval  would  allow 
the  FAMIS  DSS  to  answer  ad  hoc  questions  which  had  not  been 
previously  identified. 

A  disadvantage  of  a  relational  database  system  is  the 
direct  tradeoff  between  data  access  speed  and  the  amount  of 
memory  storage  necessary.  A  relational  database  increases 
access  speed  to  data  by  creating  more  indexes  to  group  the 
data  in  more  numerous  logical  ways.  The  increased  number  of 
indexes  take  up  more  memory  space.  However,  the  decreasing 
costs  for  memory  storage  hardware  and  the  increasing 
capacity  of  microcomputers  to  house  thirty  and  even  forty- 
megabyte  hard  disks  render  this  disadvantage  unimportant  for 
purposes  of  FAMIS  application. 

C.   NETWORK  TYPE  DATABASE 

Unlike  hierarchical  or  relational  databases,  which  use 
one-to-one  and  one-to-many  data  relationships,  a  network 
database  type  uses  many-to-many  data  relationships.  A 
network  database  defines  sets  which  contain  rules  for  asso- 
ciation of  relationships  between  logical  groups  of  data. 
Such  a  database  type  is  effective  for  retrieving  large 
amounts  of  data,  but  is  inappropriate  for  answering  ad  hoc 
queries  since  this  involves  redefining  data  relationships. 
Such  redefinition  is  more  difficult  when  the  relationships 
are  defined  by  sets.  A  network  database  system,  such  as 
CODASYL,  would  be  inappropriate  for  FAMIS  due  to  this 
shortcoming. 
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D.   FUNCTIONAL  TYPE  DATABASE  (ENTITY  RELATIONSHIP) 

An  entity  relationship  database  describes  data  as  enti- 
ties and  extracts  information  by  assigning  functions  to 
these  entities  to  establish  relationships.  Purported  to 
most  closely  resemble  human  thought  association  methods, 
entity  relationship  type  databases  are  still  in  pre- 
production  phases  and  are  therefore  not  suitable  for  consid- 
eration with  FAMIS. 

Once  the  decision  of  which  type  of  database  FAMIS  will 
use  has  been  made,  user  data,  resource  data  and  other  data 
will  be  entered  into  the  database  to  incorporate  necessary 
keys  into  the  data.  At  that  time,  the  issue  of  data  design 
must  be  addressed.  Data  design  refers  to  the  structure  of 
the  data.  Use  of  the  existing  FAMIS  data  design  would  prob- 
ably be  preferable  to  use  of  a  new  data  design  because  data 
already  exists  in  the  FAMIS  format  and  because  a  new  data 
design  might  not  be  useable  with  other  FAMIS  programs,  such 
as  the  disaster  model. 

Updating  the  database  will  be  critical  to  successful  use 
of  the  FAMIS  system.  Any  DSS  is  only  as  good  as  the  data  it 
uses.  If  the  FAMIS  manager  allocates  resources  to  users  who 
no  longer  work  in  their  designated  functions,  the  system 
will  not  work  effectively.  However,  data  integrity  must  be 
maintained  to  ensure  updates  of  information  in  the  database 
do  not  remove  or  alter  information  which  will  be  needed  at  a 
future  time.  To  preserve  data  integrity,  it  is  recommended 
that  the  FAMIS  DSS  maintain  two  sets  of  databases.  One  set, 
consisting  of  recovery  agent  and  communication  resource 
information,  would  reflect  pre-disaster  information  and 
would  not  be  updated.  This  database  would  be  reserved  as 
the  starting  point  for  initial  FAMIS  calculations  and  as  a 
reference  point.  At  the  beginning  of  the  FAMIS  DSS  exer- 
cise, a  second  set  of  databases  would  be  duplicated  from  the 
master   set.    This   second   set  could   then  be  updated   to 
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reflect  current  information,   while  leaving  the  master  data- 
base set  unchanged. 

An  example  will  illustrate  the  wisdom  of  maintaining  two 
database  sets.  Suppose  a  region  is  reported  destroyed.  The 
FAMIS  manager  would  update  the  databases  to  reflect  the 
destruction  of  reccery  agents  and/or  communication 
resources.  If  subsequent  reports  refuted  the  original 
report  of  destruction,  the  FAMIS  manager  could  recall  the 
original  data  to  correct  the  updated  database  if  he  had  an 
original  master  database  as  a  reference.  Without  the  orig- 
inal database,  the  FAMIS  manager  would  have  no  certain  way 
to  reconstruct  the  existing  communication  resources. 
Updating  the  database  of  the  FAMIS  DSS  will  be  harder  on  a 
microcomputer  than  on  a  mainframe  computer  because  the 
microcomputer  is  portable  and  therefore  not  always  readily 
accessible.  The  Red  Cross  handles  such  an  access  problem  by 
updating  database  information  on  a  periodic  basis  before 
disaster  strikes.  Such  a  procedure  is  recommended  for  the 
FAMIS  system  for  two  reasons. 

First,  by  knowing  when  updates  will  occur,  the  FAMIS 
manager  will  know  how  current  his  database  "information  is 
and  when  he  can  expect  the  next  update. 

Second,  these  updates,  which  would  originate  with  FAMIS 
geographic  area  field  representatives,  present  an  excellent 
method  of  maintaining  contact  between  the  field  representa- 
tives and  the  FAMIS  manager.  Such  contact  ensures  the 
viability  of  the  data  received  by  the  FAMIS  manager  about 
the  current  status  of  resources  and  users.  Such  contact 
also  ensures  the  FAMIS  manager  knows  who  and  where  his  field 
representatives  are,  so  he  can  pass  policy  and  other  deci- 
sions down  to  them. 

The  updates  could  be  done  via  telephone  modem  hookup  or 
by  floppy  disks  mailed  to  updating  locations.  Each  method 
has   advantages.     The  modem   method   allows   instantaneous 
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update  of  the  database,  without  the  time  lag  of  mail 
service.  The  floppy  disk  method  does  not  require  the  FAMIS 
manager  and  field  representatives  to  be  connected  to  the 
same  network  at  the  same  time. 

The  data  included  in  the  FAMIS  DSS  database  will  be 
determined  by  the  types  of  questions  the  DSS  must  address. 
Most  of  this  information  has  already  been  identified  by 
FAMIS  developers,  although  provision  must  be  made  for  inclu- 
sion of  other  data  which  is  determined  to  be  germaine  to 
FAMIS  use. 

A  relational  database,  governed  by  a  DBMS,  will  effec- 
tively accommodate  the  FAMIS  data  and  associated  indexes  as 
well  as  provide  methods  to  incorporate  new  data  into  the 
existing  database. 

Updates  of  the  data  will  be  imperative.  To  be  effec- 
tive, these  updates  must  be  frequent  enough  to  ensure  the 
FAMIS  database  reflects  current  information.  The  necessary 
frequency  of  such  updates  will  depend  on  how  often  the  data 
changes.  The  updates  should  be  performed  following  a 
regular  schedule.  Such  regularity  promotes  maintenance  of 
current  data,  since  the  FAMIS  manager  will  know  when  to 
expect  an  update  and  therefore  will  know  if  he  has  missed 
one. 

This  thesis  will  not  attempt  to  specify  all  types  of 
data  needed  by  the  FAMIS  DSS.  As  the  FAMIS  project  develops 
and  its  scope  of  responsibility  is  finalized,  the  amount  and 
type  of  data  will  be  identifiable.  This  chapter  has 
attempted  to  provide  possible  arrangement  of  that  data  in  a 
database  and  suggested  manipulation  of  the  data  by  a  Data 
Base  Management  System. 
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VI.  THE  ADJUDICATION  ALGORITHM 

This  chapter  will  present  a  possible  adjudication  algo- 
rithm to  be  used  to  resolve  claims  made  by  recovery  agents 
for  scarce  communication  resources.  Switching  facilities  of 
the  Public  Switched  Network  will  be  briefly  described  to 
provide  background  for  the  algorithm.  A  possible  claim 
problem  will  be  isolated  and  discussed.  The  possible  algo- 
rithm process  will  be  presented  and  the  DSS  process  involved 
will  be  discussed. 

A.   REDUNDANCY  IN  THE  PUBLIC  SWITCHED  NETWORK 

The  current  Public  Switched  Network  (PSN)  is  comprised 
of  switches,  nodes,  trunks  and  other  telecommunications 
equipment  which  serve  to  connect  the  system.  Many  redundant 
paths  between  any  two  points  exist  in  the  PSN.  This  redun- 
dancy was  built  into  the  PSN  to  provide  faster,  more  reli- 
able telephone  service.  Calls  can  be  rerouted  along 
alternate  routes  if  congestion  exists  on  a  primary  path. 

In  an  emergency  or  disaster,  the  built-in  redundancy  of 
the  PSN  will  serve  two  purposes.  Almost  certainly,  communi- 
cation resources  will  be  in  heavy  demand  during  an  emergency 
and  congestion  will  exist  on  certain  paths.  Additionally, 
the  emergency  or  disaster  might  destroy  some  of  the  communi- 
cation paths.  Redundancy  of  paths  will  be  used  to  relieve 
the  congestion  caused  by  the  crisis,  but  such  redundancy 
will  also  improve  the  probability  that  a  working  path  still 
exists  between  two  points  where  disaster  has  eliminated 
primary  communication  paths. 

As  will  be  seen  in  the  claim  problem  examined  in  this 
chapter,  the  existence  of  PSN  path  redundancy  will  be  manda- 
tory to  allow  for  allocation  flexibility.  The  FAMIS  DSS 
adjudication  algorithms  developed  to  solve  the  claim  problem 
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must  therefore  be  able  to  take   advantage  of  PSN  path  redun- 
dancy as  discussed  above. 

B.   THE  CLAIM  RESOLUTION  PROBLEM 

For  illustrative  purposes,  one  of  the  questions 
discussed  in  Chapter  4  will  be  used  as  our  example  problem, 
namely,  How  can  the  number  of  users  on  the  system  be 
maximized? 

Resolution  of  this  question  will  involve  several  steps: 

1.  Determination  of  network  status;  what  characterizes 
existing  paths. 

2.  Determination  of  user  status;  what  recovery  agents 
exist  and  where  are  they  on  the  NETS. 

3.  Determination  of  optimum  allocation;  how  to  connect 
the  greatest  number  of  recovery  agents  over  the  NETS 
simultaneously. 

These  steps  are  discussed  at  length  below. 

Certain  characteristics  of  the  NETS   can  be  discerned  by 
determination  of  network  status  as   discussed  in  Chapter  IV. 
For  allocation  purposes  in  our  example  problem,   the  charac- 
teristics of  connectivity  and  capacity   of  the  paths  will  be 
the  relevant  parameters  of  the  NETS. 

J.  LaPatra  and  C.  Pierson  have  developed  a  Coefficient 
of  Connectivity  (CC),  which  defines  mathematically  all 
possible  paths  between  two  nodes  (recovery  agents)  within 
the  PSN  [  Ref .  6]  .  Since  the  CC  can  be  defined  for  every 
possible  path  within  the  PSN,  it  can  also  be  defined  for  any 
remaining  paths  in  NETS,  since  such  remaining  paths  will  be 
a  subset  of  the  original  PSN. 

Given  this  ability  to  express  every  NETS  path  mathemati- 
cally, the  FAMIS  DSS  could  determine  the  capacity  of  these 
paths.  Such  determination  would  involve  retrieving  the 
capacity  information  for  these  paths  from  the  DSS  database 
and  applying  an  update  from  the  FAMIS  manager  to  that  infor- 
mation. Using  a  comparison  program,  the  FAMIS  DSS  could 
then  determine  the  lowest  channel  capacity  link  within  this 
subset  of  system  paths,  since  the  capacity  of  any  path  can 
never  exceed  the  capacity  of  its  weakest  link. 
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It  should  be  emphasized  that  all  paths  in  the  PSN  can  be 
expressed  individually  in  terms  of  the  CC  mentioned  above. 
All  PSN  paths  could  therefore  be  defined  in  the  FAMIS  commu- 
nication resource  database  by  their  CCs,  rather  than  by 
numbered  node  connections  or  geographic  positions.  Such 
definition  by  CC  would  make  it  easier  for  the  FAMIS  DSS  to 
express  the  NETS  status  mathematically  in  optimization 
models. 

The  determination  of  user  status  was  discussed  in 
Chapter  IV.  The  user  characteristics  of  interest  in  our 
example  problem  would  be  communication  line  capacity 
requirements  and  time  requirements,  since  these  requirements 
will  determine  which  lines  will  meet  the  needs  of  certain 
recovery  agents  and  the  duration  of  their  calls  will  deter- 
mine how  many  users  can  be  queued  for  calls. 

The  FAMIS  DSS  would  retrieve  these  user  characteristics 
from  the  recovery  agent  database.  Note  that  user  priority 
is  not  mentioned  as  a  characteristic  in  our  example.  This 
omission  is  due  to  the  emphasis  on  number  of  users,  instead 
of  priority  use. 

The  FAMIS  DSS  could  then  employ  an  optimization  model  to 
maximize  recovery  agent  use  of  the  NETS,  subject  to  the 
constraints  of  existing  system  connectivity,  lowest  path 
capacity,  user  capacity  requirements  and  user  time  require- 
ments. This  optimization  model  could  easily  be  adjusted  to 
answer  the  other  allocation  questions  listed  in  Chapter  IV 
by  altering  the  constraints. 

The  example  problem  discussed  in  this  chapter  is  only 
one  of  several  questions  addressed  in  Chapter  IV,  which  does 
not  address  all  possible  ad  hoc  questions  the  FAMIS  manager 
might  have  to  answer  to  resolve  all  possible  contingencies 
of  communication  resource  allocation.  The  characteristics 
of  the  NETS  and  the  recovery  agents  can  be  combined  in  many 
ways   and    each   combination   might   require    a   different 
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allocation  configuration.  The  example  discussed  in  this 
chapter,  however,  is  typical  of  the  type  of  optimization 
problem  which  the  FAMIS  manager  and  his  DSS  will  be  required 
to  resolve. 
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VII.  THE  FAMIS  DSS 

This  chapter  will  describe  the  required  attributes  of  a 
decision  support  system  for  use  with  FAMIS.  The  three  parts 
of  any  DSS  will  be  described  briefly  to  define  the  inter- 
faces between  the  manager  and  the  DSS.  Required  and  desired 
technical  literacy  of  the  manager  will  be  discussed  and 
coupled  with  necessary  DSS  functions.  Finally,  the  informa- 
tion presented  in  this  thesis  will  be  summarized  to  identify 
required  and  desired  characteristics  of  the  FAMIS  DSS. 

A.   COMPONENTS  OF  A  DECISION  SUPPORT  SYSTEM 

Decision  Support  Systems  have  been  described  in  many 
different  terms  and  categories.  All  decision  support 
systems,  however,  are  composed  of  the  same  three  basic 
systems:  Language  System  (LS),  Knowledge  System  (KS),  and 
Problem-Processing  System  (PPS).  These  three  generic  DSS 
systems  are  described  briefly. 

KS.  A  knowledge  system  in  a  DSS  is  the  body  of  knowl- 
edge a  decision  support  system  uses  to  answer  questions. 
Databases,  files  and  other  stores  of  information  are  common 
parts  of  a  KS.  Information  contained  in  a  KS  must  be 
arranged  in  a  systematic,  organized  manner.  The  KS  portion 
of  the  FAMIS  DSS  would  include  recovery  manager  information, 
resource  information,  any  standard  arithmetic  rules  inherent 
in  computer  calculations  and  any  other  information  which  the 
DSS  would  retrieve  and  use  to  answer  a  question. 

LS.  A  DSS  language  system  serves  as  the  interface 
between  the  manager  and  the  DSS.  The  LS  can  be  defined  as 
the  total  of  all  linguistic  facilities  made  available  to  the 
manager  by  a  DSS.  As  will  be  discussed  later  in  this 
chapter,  this  interface  can  be  designed  to  be  as  complex  or 
as  simple  as  required  to  be  understandable  to  the  manager. 
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PPS.  The  problem-processing  system  of  a  DSS  takes  the 
problems  conveyed  by  the  LS  and,  retrieving  data  from  the 
KS,  solves  equations,  compares  data  and  otherwise  analyzes 
and  interprets  data  to  provide  information  requested  by  the 
manager. 

The  terms  language  system,  knowledge  system  and  program- 
processing  system  represent  logical  entities  rather  than 
strict  physical  components  and  there  can  be  blurring  of  the 
lines  of  responsibility  between  these  three  sections. 
Different  decision  support  systems  will  allocate  certain 
functions,  such  as  standard  arithmetic  functions,  to  the  PPS 
instead  of  the  KS.  The  DBMS  might  also  reside  in  the  PPS 
instead  of  the  KS.  It  is  important  to  realize  that  these 
sections  are  defined  broadly  because  each  DSS  will  be 
arranged  to  suit  its  specific  purpose. 

The  KS,  arranged  logically,  interfaces  with  the  PPS 
through  a  Data  Base  Management  System  (DBMS).  As  discussed 
in  Chapter  IV,  the  DBMS  is  a  software  program  and  it  can 
reside  in  either  the  KS  or  the  PPS.  The  DBMS  retrieves 
selected  information  in  a  specified  format  from  the  KS  and 
delivers  this  information  to  either  the  PPS  or  the  LS, 
depending  on  whether  the  data  must  be  acted  upon  or  simply 
passed  to  the  manager. 

If  the  data  must  be  analyzed,  calculated  on  or  somehow 
transformed,  the  DBMS  sends  the  data  to  the  PPS.  For 
example,  in  the  FAMIS  DSS  the  DBMS  would  retrieve  data 
showing  historical  resource  locations  along  with  disaster 
model  results  and  place  the  information  into  the  PPS.  The 
PPS  would  then  compare  the  two  data  stores  to  determine  the 
percentage  and  location  of  remaining  resources.  This  infor- 
mation would  be  sent  to  the  manager  via  the  LS  and  would 
also  be  sent  to  the  KS  for  retention  for  future  use. 

For  simple  data  retrieval,  such  as  when  the  FAMIS 
manager  wishes   to  see  a  graphic   display  of  the   NETS,   the 
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DBMS  would  take  the  location  data  from  the  KS  and  send  it 
directly  to  the  LS.  The  LS  would  produce  the  graphic  soft- 
ware necessary  to  project  the  map  onto  the  manager's  screen. 

B.   THE  FAMIS  MANAGER 

Of  the  three  DSS  systems  described,  the  language  system 
(LS),  as  the  interface  between  the  DSS  and  the  manager,  will 
reflect  to  the  greatest  degree  the  FAMIS  manager's  level  of 
computer  literacy.  The  manager  must  be  able  to  request 
information  from  the  DSS.  He  must  also  be  able  to  under- 
stand the  answers  the  DSS  produces.  If  the  manager  has 
little  computer  experience,  then  the  LS  must  allow  the 
manager  to  ask  his  questions  in  simple  terms,  perhaps  as 
simple  as  colloquial  English  phrases,  and  must  present  the 
requested  information  in  equally  understandable  terms, 
perhaps  as  simple  as  annotated  map  displays  for  depiction  of 
NETS. 

An  example  of  a  data-retrieval  type  of  DSS  which  allows 
the  user  to  ask  questions  in  colloquial  English  is  the 
Language  Access  to  Distributed  Data  with  Error  Recovery 
(LADDER)  system  used  on  the  ARPANET  system.  LADDER  is 
written  in  a  complex  computer  language  called  INTERLISP. 
The  designers  of  the  LADDER  program  assumed  the  user  would 
have  no  computer  experience  and  they  designed  the  program  to 
accept  questions  and  present  answers  in  colloquial  English. 
LADDER  will  accept  questions  that  are  not  couched  in 
complete  sentences  and  will  even  try  to  figure  out  the 
possible  meaning  of  misspelled  words.  This  feature  allows 
users  who  are  not  comfortable  "talking"  with  a  computer  to 
convey  their  wishes  to  the  system  and  receive  usable  infor- 
mation back. 

The  LADDER  system  is  somewhat  slow,  however,  because  the 
LS  interface  is  so  complex.  The  LS  of  any  DSS  must  convert 
the  user's  requests  into  high-level  computer  code  the  PPS 
can  accept  to  perform  its  tasks.   If  the  user's  requests  are 
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couched  in  varied  English  phrases,  the  LS  must  have  within 
itself  the  necessary  software  to  convert  the  English  phrases 
to  syntactically  correct  code.  An  additional  problem  with 
LADDER  is  that  its  LS  will  attempt  to  discern  meaning  from 
whatever  phrases  it  receives  and  it  sometimes  misinterprets 
the  user's  meaning. 

These  two  problems,  slow  speed  and  possible  inaccuracy, 
are  intolerable  in  an  emergency  DSS.  An  LS  which  will 
accept  input  as  unspecific  as  LADDER'S  does  is  therefore 
unsuitable  for  the  FAMIS  DSS.  It  follows  that  the  FAMIS 
manager  must  be  at  least  somewhat  familiar  with  computer  use 
and  methods  of  inputting  and  retrieving  information. 

From  the  LADDER  example  described  above,  it  can  be 
inferred  that  the  more  computer  knowledge  the  FAMIS  manager 
has,  the  less  complex  the  LS  has  to  be  and  the  faster  the 
system  will  operate.  It  is  not  practical  to  assume, 
however,  that  the  FAMIS  manager  should  be  able  to  couch  his 
questions  in  high-level  or  pseudo  code  for  several  reasons. 

First,  the  FAMIS  manager  will  most  probably  be  a  high- 
level  government  official.  This  presumption  is  based  on  the 
fact  that  the  FAMIS  manager  will  be  given  full  authority  to 
allocate  communication  assets  nationwide  during  an  emer- 
gency. As  such  an  official,  the  FAMIS  manager  can  be 
assumed  to  have  a  sound  managerial  background  but,  because 
computer  literacy  is  only  now  becoming  a  requisite  mana- 
gerial skill,  it  cannot  be  assumed  that  he  will  have  worked 
with  computers  extensively  before. 

Second,  during  an  emergency  the  FAMIS  manager  may  not 
have  time  to  convert  his  questions  from  English  into  pseudo 
code  or  high-level  code  before  entering  them  into  the  DSS. 

Third,  since  the  LS  interfaces  with  the  PPS,  it  can  act 
as  a  buffer  to  ensure  the  PPS  receives  information  requests 
in  the  correct  format.  A  simple  LS  allows  the  manager  to 
interface  more  directly  with  the  PPS  and  may  result  in  inac- 
curate information  being  produced  by  the  PPS. 
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It  follows  from  this  discussion  that  the  FAMIS  manager 
must  possess  at  least  some  computer  experience,  but  that  he 
cannot  be  expected  to  know  computer  languages.  The  LS  must 
require  some  structure  of  format  in  the  requests  it  receives 
from  the  manager,  but  must  still  be  sufficiently  "user- 
friendly"  to  be  understood  by  the  manager. 

A  menu-driven  LS  is  a  possible  compromise.  Menus  in  a 
computer  program  can  be  described  as  lists  of  choices  which 
are  presented  to  the  user.  The  current  FAMIS  prototype 
computer  program  uses  a  menu  to  present  the  types  of  infor- 
mation available  to  the  manager.  This  list  was  presented  in 
Chapter  II.  The  benefit  of  an  LS  which  uses  menus  is  that 
it  is  readily  understandable  by  almost  any  user.  The  disad- 
vantage of  a  menu-  driven  LS  is  that  the  choices  of  informa- 
tion the  manager  can  receive  are  limited  to  the  choices 
presented  by  the  menu.  Such  limitation  of  choices  would  be 
unacceptable  where  the  FAMIS  manager  wanted  to  ask  ad  hoc 
types  of  questions,  but  could  be  used  to  initiate  broader 
requests  such  as  calling  up  a  graphic  map  of  the  NETS  or  a 
list  of  all  recovery  managers. 

Whatever  language  system  is  selected  for  FAMIS,  it  must 
satisfy  the  criteria  that  it  be  understandable  to  a  manager 
with  the  projected  computer  experience  level  of  the  FAMIS 
manager.  Since  the  FAMIS  manager  will  most  probably  be  a 
high-level  government  official  and  therefore  hard  to  find  or 
replace,  it  will  be  much  more  efficacious  to  tailor  the  LS 
to  the  manager  than  to  require  the  manager  to  become  a 
computer  expert. 

C.   CONCLUSION 

This  thesis  has  strived  to  identify  the  requirements  of 
a  decision  support  system  to  be  used  to  help  adjudicate 
allocation  of  scarce  communication  resources  in  concert  with 
the  Fly-Away  Management  Information  System. 
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As  with  any  emergency  DSS,  the  FAMIS  DSS  must  support 
the  three  criteria  mandatory  for  emergency  decisions:  accu- 
racy, speed  and  interpretation  of  large  amounts  of  uncorre- 
cted data.  This  thesis  maintains  these  criteria  can  be 
best  supported  by  a  computer-driven  DSS,  housed  in  a  micro- 
computer. Three  examples  of  such  emergency,  computer-driven 
support  aids  were  given.  Although  only  one  of  the  examples 
involved  allocation  of  scarce  resources  (ambulances),  the 
nature  of  the  decisions  faced  by  managers  in  all  three  exam- 
ples supports  the  necessity  of  a  DSS  which  can  support  the 
three  criteria  mentioned  above. 

The  FAMIS  DSS,  like  a  human  staff,  must  be  able  to 
provide  the  FAMIS  manager  with  information  upon  request  and 
must,  at  the  same  time,  screen  the  information  to  ensure  the 
manager  does  not  have  to  deal  with  data  unnecessary  to  reach 
his  decision.  Various  software  programs  exist  to  perform 
these  two  categories  of  functions  and  most  of  those  will 
work  easily  in  a  microcomputer. 

The  questions  associated  with  the  allocation  decisions 
the  FAMIS  manager  must  address  are  at  the  core  of  the  issues 
of  DSS  design  and  the  way  in  which  the  FAMIS  DSS  fits  in 
with  the  rest  of  FAMIS.  These  questions  can  be  grouped  into 
the  four  main  categories  described  in  Chapter  IV.  It  will 
be  the  FAMIS  manager's  ability  to  address  these  questions, 
using  the  DSS,  which  will  make  the  DSS  such  a  vital  part  of 
the  Fly-Away  Management  Information  System. 

The  type  of  database  and  Data  Base  Management  System 
(DBMS)  to  access  the  data  will  be  important  considerations 
for  the  FAMIS  DSS.  A  relational  database  is  recommended 
because  it  offers  the  data  flexibility  necessary  to  enable 
the  FAMIS  manager  to  ask  ad  hoc  questions  of  the  DSS. 
Regular  updates  of  the  data  will  be  vital.  Without  current 
information,  the  DSS  and  therefore  the  decisions  of  the 
FAMIS  manager  will  be  inaccurate. 
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An   example  of   a  possible   adjudication  algorithm   for 
allocation  of  scarce  resources  was   discussed  in  Chapter  VI. 
Many  other  algorithms  will  be  needed  to  provide  the  analysis 
necessary  to  resolve  all  allocation  questions. 

Possibly  the  most  important  part  of  the  FAMIS 
manager/DSS  system  will  be  the  computer  literacy  of  the 
FAMIS  manager.  The  DSS  language  system  interface  must  be 
tuned  to  the  manager's  computer  sophistication,  since  the 
DSS  will  be  useless  if  the  manager  cannot  input  information 
or  understand  the  DSS  output. 

Figure  7. 1  depicts  the  flow  of  information  into  and  out 
of  the  FAMIS  DSS 

as  discussed  in  this  thesis.  From  Figure  7. 1,  it  can  be 
seen  that  the  DSS  will  need  information  from  the  recovery 
agents  and  communication  resource  databases,  the  FAMIS 
damage  model  program,  and  the  FAMIS  manager  himself,  along 
with  the  real-time  resource  claims  of  recovery  agents  to 
determine  resource  allocation  recommendations.  These  recom- 
mendations must  be  sent  to  the  FAMIS  manager,  not  directly 
to  the  NETS,  because  the  FAMIS  manager  must  be  the  final 
arbeiter  of  allocation  demands. 
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Figure    7. 1         Interaction   of   the   FAMIS   DSS. 
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